The invention relates generally to the field of telecommunications, and more particularly to systems and methods for improving the filtering of electronic messages.
Electronic messaging has become commonplace. It is widely available to users in the workplace, at home, and even on remote devices like cellular phones and personal digital assistants. E-messaging takes very many forms, such as e-mail, instant messaging, Multimedia Messaging System (MMS) messages, and the like. As used throughout this document, the terms “e-messaging” and “messaging” will be used interchangeably to include any form of electronic communication using messages, regardless of the particular format or structure of messages, or protocols employed.
The ubiquitous nature of e-messaging coupled with its relatively-low cost (and the ability for anyone to send a message to practically anyone else) has made unsolicited commercial e-messages—commonly referred to as “spam”—one of the most often cited nuisances of the technological age. Remote devices are especially sensitive to spam because of their storage space constraints and bandwidth limitations, plus the difficulty of managing large numbers of messages on a small screen and with limited keys. In response, anti-spam filtering mechanisms are being developed to combat this plague. As forms of e-messaging such as MMS (Multimedia Messaging System) and mobile e-mail become more popular, spam is expected to be an increasing problem.
In the context of this document, “message filtering” means making a determination or decision about messages, such as if a message should be downloaded, retrieved, accessed, displayed, deleted, or otherwise acted on. Typically, message filtering is performed based on the results of a “message analysis,” which may be any evaluation of a message to determine, quantify, or qualify some characteristic of the message.
Message filtering takes different forms, but generally speaking it is performed either on a server prior to delivering the messages to a client, or at the client after the messages have been received. Examples of message filtering technologies are many, and include Bayesian filtering and rules-based filtering, such as looking for matches to fixed strings anywhere or in specific fields within the message content or protocol, looking for particular situations in specific fields in the message content or protocol (such as long runs of white space in the message subject, a subject or from address which ends in a number, a subject which starts with “Re” in a malformed way (such as lack of colon or space following “Re”), a subject which starts with “Re” in a message which does not contain an “In-Reply-To” header), looking for anomalies in the protocol, and the like.
A common feature of existing message filter technologies is that the filtering decision is essentially made using criteria and resources local to the device upon which the decision is made. In other words, a server-side filtering mechanism uses resources resident at the server and based on criteria stored at the server. On the other hand, a client-side filtering mechanism uses resources resident on the client and based on criteria stored at the client. This poses a problem for several reasons.
For instance, more sophisticated and effective message filters consume larger amounts of storage space and/or processing power, which are limited commodities on many remote devices. This dilemma suggests that the most effective message filtering can only be done at the server.
In addition, subscribers often have a different spam tolerance depending on what client the subscribers use to retrieve their messages. For instance, a subscriber may be willing to accept a higher likelihood of receiving a spam message (a “higher spam threshold”) on his desktop computer that likely has ample storage space, a fast network connection, a full keyboard, and a large screen in exchange for a greater confidence that real messages are not inadvertently blocked. Conversely, that same user may have a much lower spam threshold if retrieving his messages on a remote device.
In addition to the device, the same subscriber may wish to employ different thresholds in different circumstances. For example, a subscriber may want to only see messages that have a very low likelihood of being spam when in a hurry, using a device while roaming, when on a slow dial-up connection, when network access charges are higher, and so forth.
These types of device-specific and/or situational filtering thresholds have been largely ignored by the message filtering industry. An adequate solution to these problems has eluded those skilled in the art, until now.